Scenario #9048: A Global Admin Can Permanently Delete a Subject

A subject which is gone for good can be permanently deleted, together with all of its grants. This is destructive and irreversible; to just deactivate a USER or GROUP subject, synchronize it with deactivated: true instead. As a safeguard against deleting the wrong subject, the DELETE request has to repeat the subject’s name and type as query parameters, which are verified against the subject identified by the UUID in the path.

Properties

Required

• SubjectSync: sync-alicia (successor) from 9038: A New Subject with a New Uuid Is Created Despite a Deactivated Subject with the Same Name

Given

name	value
subjectUuid	238a0005-0000-0000-0000-000000000005
subjectName	sync-alicia
subjectType	USER

Permanently delete the subject via DELETE

HTTP DELETE "/api/rbac/subjects/238a0005-0000-0000-0000-000000000005?name=sync-alicia&type=USER" // SubjectSync: sync-alicia (successor) \
  -H "Authorization: Bearer $HSADMINNG_JWT_BEARER" \
  `# {` \
  `#   "sub" : "uuid<hsh-alex_superuser>"` \
  `# }`
=> status: 204 NO_CONTENT 

The deleted subject is gone

HTTP GET "/api/rbac/subjects/238a0005-0000-0000-0000-000000000005" // SubjectSync: sync-alicia (successor) \
  -H "Authorization: Bearer $HSADMINNG_JWT_BEARER" \
  `# {` \
  `#   "sub" : "uuid<hsh-alex_superuser>"` \
  `# }`
=> status: 404 NOT_FOUND 

---

generated on 2026-08-10 04:42:42 for branch HEAD